Day 2 - 用 Claude Code 建立第一個產品情境 Skill

今天開始動手：把 FlowBoard 的產品背景寫成 Claude Code 可以重複使用的第一個 Skill。

先解決一個更基本的問題：每次開新對話時，不要重新貼上產品背景、使用者、限制和目前未知。

今天要完成什麼

今天會在一個 Claude Code 專案中建立這個檔案：

.claude/
└── skills/
    └── product-context/
        └── SKILL.md

完成後，我們可以在 Claude Code 中輸入：

/product-context

也可以直接問：「請根據 FlowBoard 的產品情境，檢查這句需求缺少哪些證據？」讓 Claude Code 在相關任務中自動載入這個 Skill。

Claude Code 的 Skill 是放在特定目錄裡的 SKILL.md。
專案級 Skill 放在 .claude/skills/<skill-name>/SKILL.md，可以和產品程式碼、文件一起放進 Git；
個人級 Skill 則放在 ~/.claude/skills/<skill-name>/SKILL.md，會套用到自己的所有專案。Claude Code 官方文件

Skill 情境卡

Skill 應該保存可重複使用的工作背景和判斷邊界，讓 Claude Code 知道哪些是目前資料、哪些只是待驗證假設。

產品情境卡至少要區分四類資訊：

• 已知事實：目前材料直接支持的內容。
• 假設：合理但尚待驗證的解釋。
• 目標：團隊想改變的結果，不等於已承諾數字。
• 限制：時間、技術、政策與研究範圍。

最常見的錯誤，是把「客服常聽到」寫成「大多數使用者都會」，或把「不知道下一步」直接翻譯成「需要導覽精靈」。前者擴大證據，後者跳過問題探索。

GOV.UK 服務手冊建議把未經支持的假設改成研究問題，再依研究目標選擇方法。這個原則也會寫進我們的 Skill，避免後面的 Claude Code 把推論說成事實。

FlowBoard 的產品情境卡

以下全部為教學用模擬資料。

注意問題陳述中的「可能」。目前只有模擬文字回饋，不能直接推導留存或營收影響。這個保留會成為 Skill 的規則：沒有證據時，必須標記「待驗證」，不能自行補上結論。

建立第一個 Claude Code Skill

先切到你的練習專案。若你還沒有專案，可以建立一個空資料夾：

mkdir flowboard-claude-skills
cd flowboard-claude-skills
mkdir -p .claude/skills/product-context

接著建立 .claude/skills/product-context/SKILL.md：

---
name: product-context
description: FlowBoard 產品背景與問題邊界。當任務涉及新成員啟用、產品需求、競品分析或 PRD 時使用；不要把待驗證假設寫成事實。
---

# FlowBoard 產品情境

以下內容是教學用模擬資料，不是真實研究結果。

## 產品與使用者

- 產品：FlowBoard，服務 10–50 人團隊的專案協作 SaaS
- 使用者：第一次加入既有工作區的新成員
- 情境：收到邀請、登入工作區，準備參與第一個專案

## 目前問題

新成員進入後不確定該先查看專案、建立任務或等待指派，可能延後第一次有價值的行動。

## 現有證據

- 8 則教學用模擬客服回饋提到找不到任務、看不懂首頁或不知道下一步
- 尚無行為數據佐證

## 待驗證假設

- 首頁缺乏情境提示
- 權限與空白狀態可能造成困惑
- 不同角色可能需要不同起點

## 邊界與規則

- 不把假設改寫成研究結論
- 不直接指定功能解法
- 資訊不足時標記「待驗證」並列出需要的資料
- 本輪不重做整套權限、不處理管理者邀請轉換、不承諾提升留存
- 先支援桌面網頁版，概念驗證時間為兩週

這個檔案有兩個部分。YAML frontmatter 告訴 Claude Code 這個 Skill 叫什麼、什麼時候適合使用；下面的 Markdown 才是實際載入後要遵守的背景與規則。description 特別重要，因為 Claude Code 會用它判斷是否自動載入 Skill。

不要一開始就把所有研究資料、完整 PRD 和十幾頁規格塞進 SKILL.md。Skill 載入後會留在目前對話的上下文裡；詳細資料可以在之後拆成獨立的 reference 檔案。今天先保持短小，讓我們看得出它到底改變了什麼。

實際啟動 Claude Code

在同一個專案資料夾執行：

claude

進入 Claude Code 後，先直接用斜線指令測試：

/product-context

接著輸入一個需要產品背景、但不能直接跳到解法的問題：

請根據目前的 FlowBoard 產品情境，檢查以下需求描述：

「新增新手導覽，讓新成員更快完成啟用。」

請分成四欄回答：
1. 這句話中的已知事實
2. 可能偷渡的假設
3. 尚未回答的問題
4. 需要補哪些證據

不要提出功能方案，也不要自行補充 FlowBoard 沒有提供的資料。

理想輸出不應該直接幫你設計導覽流程，而是指出「新增新手導覽」已經是解法、「更快完成啟用」沒有定義完成事件，而且目前沒有行為數據支持成效。

實際執行後會看到兩件事。第一，/product-context 出現在斜線指令選單，右側是 description 的內容：

第二，Claude Code 會把「功能願望」拆回事實、假設與待補證據，而不是直接設計導覽流程：

截圖時保留專案路徑和指令，但移除帳號、API 金鑰、公司名稱與真實使用者資料。

如果 Claude Code 沒有自動載入

先檢查三件事：

1. 目前 Claude Code 是否從 flowboard-claude-skills 啟動？
2. 檔案是否真的位於 .claude/skills/product-context/SKILL.md？
3. SKILL.md 的 frontmatter 是否以 --- 開始並正確結束？

也可以先用 /product-context 明確呼叫。明確呼叫成功後，再測試自然語言自動觸發：

我正在檢查 FlowBoard 新成員啟用問題，請先列出目前已知事實、待驗證假設與資料缺口。

如果自然語言沒有觸發，優先修改 description 的「何時使用」描述，不要立刻把整份 Skill 寫得更長。Skill 的名稱、描述和觸發情境要清楚分工：名稱讓人看得懂，描述讓 Claude Code 判斷何時載入，正文才放實際規則。

人類仍然要做的決策

Skill 可以保存背景和檢查規則，但不能替產品經理確認問題是否真實存在。今天仍要由人確認：

• 這 8 則回饋是否真的來自目標使用者。
• 「第一次有價值行動」要怎麼定義。
• 哪些內容是資料直接支持，哪些只是團隊假設。
• 題目是否值得用接下來 30 天繼續研究。

涉及真實使用者資料時，先依組織政策去識別化，移除姓名、Email、公司與可辨認內容，再交給核准的工具。

今天的產出物

今天完成三件事：

1. 一張區分事實、假設、目標與限制的 FlowBoard 產品情境卡。
2. 一個可放進 Git 的 .claude/skills/product-context/SKILL.md。
3. 一次 /product-context 實際執行結果，以及一張自然語言觸發測試的截圖。

這個 Skill 只先確保後續工作使用同一份產品背景，並且把未知保留下來。
Day 3 會把「背景、任務、輸入、限制、輸出」整理成可重複使用的工作型 Skill。

參考資料

• Claude Code 官方文件：Extend Claude with skills
• GOV.UK Service Manual：Plan user research for your service